Git Flow 开发发布流程

关于 Git Flow 的基本操作，可以参考下面的参考资料：

本文档基本上是符合标准的 Git Flow 流程的，只是在部分细节（比如灰度和全量）上做了一些细化。

首先先通过流程图描述一下在开发、release 与 fix 三种场景下的流程。

第一个 开发流程 是开发人员需要遵守的流程，后面的 Feature 发布流程 和 Fix 发布流程 是运维人员需要遵守的流程。原则上，开发人员只管开发，运维人员（以及运维人员开发的自动化工具）才能进行灰度或者发布。

master 和 dev 是保留分支，无法 push -f，无法删除，所有对这两个分支的更新必须经过有权限的人授权。

开发流程

第一个流程是后台开发人员需要遵守的流程，这个流程也非常的简单。

唯一需要注意的是「squash dev 分支，并合并成一个节点」的操作可能有些学习成本。具体的命令如下：

$ git fetch --all
$ git merge --squash origin/dev

和 Fix 流程基本一样，只 revert master 上的节点，可以不做 CI 测试

稳定性测试由 gitlab ci 等工具支持，每一个 dev 和 master 分支上的节点，以及向这两个分支提了 Merge request 的分支，都会由 CI 工具自动地执行测试。

原则上来说，除非特别紧急的情况，所有代码在发布前都必须要通过持续集成的验证。

目前 CI 测试主要是稳定性测试。原则上 CI 测试应该设计成能在一个小时那执行完。

每天早上 10:00，经过人类的批准，发布脚本会从 dev 分支切出一个 rel_YYYYMMDD 分支，并开始灰度。（注意 dev 上的所有节点都已经通过了 CI 测试）

第二天早上 12:00，也就是灰度了 26 小时后，经过人类的批准，发布脚本会自动地进行全量操作。

在灰度期间，如果监测到 master 上有更新，脚本应该提醒人类帮忙合代码，并重新部署代码。

如果有刷脚本等复杂的发布操作，可以选择停用 CD 脚本，人工进行操作

和雅堂沟通过了，目前前端还没有使用 git flow 的打算。所以发布需求需要前后端进行同步：比如说后端的 release 分支中有五个新需求，那么需要提前通知前端，让前端将五个需求对应的改动合并成一个分支，并在后端开始灰度前发布好这个前端分支。